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Beschreibung 

IP iiber CAN 
1 Der CAN-Bus 

Im folgenden werden ausschlieBlich die fur das weitere Verstandnis unbedingt notwendigen 
Eigenschaften des CAN-Bus-Protokolls skizziert. Bezuglich einer detaillierten Beschreibung 
des CAN-Bus sei etwa auf die Literatur verwiesen. 




Abbildung 1: CAN Frame-Format 

In Abbildung 1 ist das CAN Frame-Format dargestellt. Der CAN-Bus bietet variable Frame- 
Langen mit 0 bis 8 Oktetts Nutzdaten, programmierbare Brutto-Ubertragungsraten bis zu 1 
MBit/s (bei 40 m Segmentlange, Verringerung der Ubertragungsrate bei groBerer Ausdehnung 
des Segments aufgrund fester Bit-Zeiten) und Nachrichten-basierte Adressierung. Letzteres 
bedeutet, daB nicht einer Station eine netzweite Adresse zugeordnet ist, die als Zieladresse in 
einem Sendevorgang dient (wie etwa MAC-Adressen bei Ethernet), sondern daB vielmehr 
jede Nachricht vorne mit einer inhaltsbezogenen Kennung behaftet ist, die anderen Stationen 
zur Auswahl von Nachrichten dient, die von ihnen empfangen werden sollen. Weil die Nach- 
richten aus Anwendungssicht als in der CAN-Hardware abgelegte, empfangene oder zu iiber- 
tragende CAN-Objekte betrachtet werden kdnnen, werden die verwendeten Kennungen auch 
als "CAN Object Identifier" (COB-BDs) bezeichnet. Diese sind entweder 11 bit oder 29 bit 
lang (Extended CAN). Heute ubliche, intelligente CAN Controller, wie das CAN Interface 
des 80C167-|i Controllers oder der CAN Controller Intel 82527, sind in der Lage, gleichzeitig 
verschiedene Sende- und Empfangs-IDs in ihren Hardware-Puffern zu konfigurieren, deren 
eigentlicher Sende- bzw. Empfangsvorgang ohne Zutun eines Prozessors abgewickelt wird. 
Zusammen mit den herausragenden Fehlererkennungs- und -behandlungsverfahren erreicht 
der CAN-Bus damit einen atomaren Multicast der gesendeten Nachricht. 

Die verwendete COB-ID einer Nachricht stellt gleichzeitig eine Prioritat dar: je niedriger die 
COB-ID ist, umso hoher wird die Prioritat der Nachricht angesehen. Die Prioritat dient der 
Bus-Arbitirierung, d.h. der Losung von Zugangskonflikten bei zeitgleichem Sendewunsch 
verschiedener Knoten. Die Konfliktauflosung geschieht, im Gegensatz zu sonst ublichen Ver- 
fahren, wahrend der Ubertxagung, ohne dabei eine Zerstorung der Nachricht hervorzurufen. 
Vielmehr setzt sich die hochstpriore Nachricht durch Verwendung sogenannter dominanter 
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(logisch 0) und rezessiver Pegel (logisch I) automatised auf dem Bus durch. Fiir niederpriore 
Nachrichten, die auf diese Weise zuruckgestellt wurden, versuchen die Knoten selbstandig 
eine eraeute Ubertragung zum nachstmoglichen Zeitpunkt. 

Da die Zuordnung einer COB-ID normalerweise zu der inhaltlichen Bedeutung der versende- 
ten Daten (z.B. Rotationsgeschwindigkeit Vorderrad links) und nicht zum sendenden oder 
empfangenden Knoten erfolgt, ergibt sich auch das Verbot fur zwei verschiedene Knoten, 
zum selben Zeitpunkt ein CAN-Paket mit derselben COB-DD zu versenden. Innerhalb des 
CAN-Protokolls ist dies nicht gestattet, da sich die beiden Nachrichten uberlagern und zu ei- 
nem nicht definierten oder zumindest fehlerhaften Zustand auf dem Bus fuhren wurden. 



2 Grobarchitektur 



A 



Der verfolgte Ansatz sieht vor, existierende TCP/IP-Stacks (wie z.B. unter PC/Windows NT) 
zu verwenden und den CAN-Bus als ein Ethernet erscheinen zu lassen. Dazu werden Ethernet 
Frames, wie sie iiblicherweise an einen Ethernet-Treiber ubergeben werden, in Stiicken iiber 
den CAN-Bus transportiert. Daher ist ein Ubertragungsprotokoll zu entwickeln, das Ethernet 
Frames durch geeignete Folgen von CAN-Paketen zwischen den beteiligten Stationen uber- 
tragt. Die fur das zu entwickelnde Ubertragungsprotokoll relevanten Informationen miissen 
dabei aus den Ethernet Headern der zu sendenden Frames extrahiert werden. 

Die resultierende Grobarchitektur ist in Abbildung 2 dargestellt. Die zu entwickelnde n Kom- 
ponenten bestehen prinzipiell aus einer CAN-Treiber-Schicht zum Umgang mit der CAN- 
Hardware und einer Ethernet-Treiber-Schicht, die nach unten mit dem CAN-Treiber kommu- 
niziert und nach oben mit dem TCP/EP-Stack interagiert. 



Standard-Anwendungen 
z.B. HTTP. FTP. SMTP 



neue, eigene 
Anwendunaen 



TCP/IP-Stack 



Z 



Standard- 
Ethernet-Treiber 







X 



Ethernet-Treiber 



CAN-Treiber 



Ethernet 



CAN 



Abbildung 2: 



Grobarchitektur des zu entwickenden Systems 
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Die dargestellte Architektur bringt groBe Vorteile mit sich. Gelingt die Emulation eines 
Ethernet-Segments vollstandig, so ist die Ubertragung liber CAN fur den TCP/IP-Stack und 
alle darauf aufsetzenden Applikationsprotokolle vollig transparent. Insbesondere bleiben alle 
Eigenschaften der EP-Ebene, die der Stack i.d.R. bereitstellt, wie Multicasting, Routing, usw. 
erhalten. Insgesamt ist damit die nahtlose Integration der Feldebene in uberlagerte Netzwerke 
gegeben. 



3 IP-Pakete und Ethernet Frames 

In diesem Abschnitt werden die grundlegenden Eigenschaften von IP-Paketen, wie sie von 
uberlagerten Protokollen wie TCP oder UDP erzeugt werden, und Ethernet Frames skizziert, 
auf die IP-Pakete in LAN-Umgebungen typischerweise abgebildet werden. Fur Details sei auf 
eines der zahlreichen Lehrbiicher zu TCP/IP verwiesen. 

Die auf der Transportebene von der sendenden Applikation zu verschickenden Daten werden 
> i.d.R. uber die Socket-Schnittstelle als TCP-Stream bzw. UDP-Pakete an den TCP/IP-Stack 

ubergeben und dort in EP-Pakete der Netzwerkebene zerlegt bzw. verpackt. Jedes EP-Paket 
wird unter Beachtung von Maximallangen als Ethernet-Frame an die unterlagerte Link-Layer- 
Schicht weitergereicht. Wie aus Abbildung 4 ersichtlich, enthalt der Ethernet- Header insbe- 
sondere die Zieladresse des Frames auf dem Ethernet-Medium. Sie wird als Media Access 
Control-Adresse (MAC-Adresse) bezeichnet und besteht gemaC dem Standard IEEE 803.2 
aus einer fur jeden jemals produzierten Ethernet-Netzwerkadapter eindeutigen 
48-bit-Kennung. Das zweite Feld, das im Ethernet Header betrachtet werden muB, ist das 
ether_type-¥z\d, in dem die Art des im Ethernet- Frame enthaltenen Pakets definiert ist. Es 
werden hier die Typen ETHERTYPE_EP fur IP-Pakete und ETHERTYPE_ARP betrachtet; 
letzteres wird durch das in den TCP/TP-Stack integrierte Address Resolution Protocol (ARP) 
zur Abbildung von IP-Adressen auf Ethernet-MAC-Adressen verwendet. 
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Abbildung 3: IP- / ARP -Paket im Ethernet-Frame 



4 Das Adressierungsproblem der Ethernet-Schicht 

Ein Grundproblem ist die Zuordnung zwischen den MAC-Adressen der Ethernet Frames und 
den CAN COB-EDs, wie sie von der CAN-Hardware fur die Ubertragung verwendet werden. 
Hierfur wird im folgenden eine Losung angegeben. 
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Der grundlegende Unterschied einer stationsorientierten Adressierung auf Ethernet-Seite irn 
Gegensatz zu nachrichtenorientierter Adressierung innerhalb des CAN-Protokolls wurde in 
Abschnitt 1 bereits geschildert. Zur Realisierung einer transparenten EP-Kommunikation zwi- 
schen den Teilnehmerknoten muB deninach eine eindeutige Adressierung einzelner Stationen 
realisiert werden. Dariiberhinaus sieht der Ethernet-Standard die Moglichkeit von Broadcasts 
und Multicasts vor, von Ethernet-Frames also, die an alle oder eine Teilmenge der am Medi- 
um angeschlossenen Stationen gleichzeitig gerichtet sind. 

CAN-basierte Netzwerkknoten sind hingegen generell in der Lage, jedes beliebige uber den 
Bus gesendete CAN-Paket zu empfangen, sofern einer der Empfangspuffer in der Hardware 
fur den betreffenden CAN-Identifier der Nachricht konfiguriert ist. Dabei muB keine eindeu- 
tige Zuordnung zu einem Puffer erfolgen, da die verwendete Hardware auch Puffer enthalt, 
deren Akzeptanz fiir einen Identifier liber ein Register maskierbar ist, so daB alle COB-EDs, 
die ein bestimmtes Bitmuster enthalten oder sogar jeder beliebige CAN-Identifier von dem 
Empfangspuffer akzeptiert wird. Ebenso ist jede Station in der Lage, CAN-Pakete mit ver- 
schiedenen, frei wahlbaren COB-DDs zu versenden, indem entsprechende Sendepuffer konfi- 
guriert werden. 

Ein einfacher, naiver Ansatz fur die Abbildung der Ethernet-Adressierung besteht darin, je- 
dem Teilnehmer eine feste COB-ID zuzuweisen. Dies kann jedoch keine stationsbezogene 
Empfangsadresse sein, da damit das Verbot verletzt wiirde, zwei CAN-Nachrichten mit der- 
selben ED gleichzeitig auf den Bus zu legen, falls die betreffende Station zum selben Zeit- 
punkt Nachrichten von zwei verschiedenen Knoten erhalten soil. Damit bliebe die Zuweisung 
der Senderkennung als die einem Knoten eindeutig zugeordnete ED. Die als Empfanger adres- 
sierte Station konnte dann aber nur noch im Datenteil der CAN-Nachricht kodiert werden; zur 
Festellung, daB sie selbst angesprochen wurde, muBte eine Station also die Gesamtheit aller 
versendeten Nachrichten zunachst empfangen, den Inhalt auswerten und die an andere Statio- 
nen gerichteten Pakete verwerfen. Zu der maximal erhdhten Systemlast kame auBerdem die 
Notwendigkeit, in den mit 8 Bytes ohnehin knapp bemessenen Nutzdaten eines jeden Pakets 
die Adresse der Zielstation unterzubringen. 
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Abbildung 4: Venvaltung fur CAN Object identifier durch COB-ID-Server 



Hier wird ein Modell entwickelt (vgl. Abbildung 5), das die genannten Probleme vermeidet, 
daflir aber einen Knoten in einem CAN-Segment als zentrale Instanz benotigt. Bei diesem 
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Knoten handelt es sich urn den sogenannten COB-ID-Server, der die Menge der verwendba- 
ren COB-EDs verwaltet. Die Menge der fur die Ethernet-Emulation verwendbaren COB-DDs 
kann frei festgelegt werden. Dadurch ist die geforderte Vertraglichkeit rnit anderen CAN- 
Protokollen auf dem CAN-Bus gewahrleistet. Fur den Transport der Nutzdaten, die Ether- 
net-Frames bilden, wird jedem Paar miteinander kommunizierender Knoten jeweils ein Paar 
von COB-EDs zugeordnet; fur die Durchfiihrung von Broadcasts erhalt jeder sendewillige 
Knoten jeweils eine COB-ED vom COB-ID-Server. Die betroffenen Empfanger verfolgen die 
Zuteilung von COB-EDs so, dafi sie sich auf den Empfang von Paketen mit diesen Identifiern 
einrichten und somit Pakete, die fur andere Stationen bestimmt sind, ignorieren. 

Die getroffenen Zuordnungen konnen ohne weiteres fur spatere Kommunikationsvorgange 
der Knotenpaare aufrecht erhalten werden; nur bei zunehmender Verknappung der freien 
COB-IDs muB der COB-ID-Server zugeteilte COB-IDs zuriickfordern. Das Protokoll zur 
Verwaltung der COB-IDs wird im folgenden Abschnitt 5 detailliert beschrieben. 

Fur eine korrekte Initialisierung muB dennoch jeder Teilnehmerknoten innerhalb der Ether- 
net-Emulation eines CAN-Segments eine eindeutige Stationsadresse besitzen, die bereits zum 
Installationszeitpunkt festgelegt wird. Diese Adresse dient zur Identifikation des Knotens in- 
nerhalb der Initialisierungsphase des Protokolls zwischen dem Knoten und dem 
COB-ID-Server. Hierzu wurde ein vorzeichenloser 16-bit- Wert gewiihlt, so daB ein theoreti- 
sches Maximum von 64k Knoten adressiert werden kann. Gleichzeitig bildet dieser Wert die 
unteren 16 Bits der Ethernet-MAC-Adresse der Station im Rahmen der Emulation; die ho- 
herwertigen Bits werden auf einen festen Prafix gesetzt, z.B. 0 (vgl. Abbildung 6). Da es sich 
hierbei nur um eine Ethernet-Emulation und nicht um das tatsachliche Medium handelt, kon- 
nen diese MAC-Adressen nicht mit denen "echter" Ethernet- Adapter an einem Segment in 
Konflikt geraten. 



32 



16 



wahlbarer Prafix 



Stat io n s n u m me r 




eindeutig 

Abbildung 5: blAC-Adressen von CAN-Knoten 



5 Das COB-ID-Server-Protokoll 

Die in den Teilnehmerknoten integrierte Ethernet-Emulationsschicht und die ApplLkation des 
COB-ID-Servers implementieren zusammen ein Protokoll,. das die Zuweisung von COB-EDs 
fur verschiedene Zwecke erlaubt sowie die FluBkontrolle im Kommunikationsablauf zwischen 
den Knoten regelt. Die Ethernet-Schicht der Teilnehmerknoten agiert als Protokollschicht 
zwischen der TCP/TP-Implementierung und dem CAN-Treiber (vgl. Abbildung 2). Ihre Auf- 
gaben bestehen in der Abbildung der Ethernet-MAC-Adressen auf COB-DDs, der Segmentie- 
rung und Reassemblierung von Ethernet Frames in CAN-Pakete sowie der Verwaltung der 
zugehorigen CAN-Objekte in der Hardware mit Hilfe des CAN-Treibers. 
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Aufgabe des COB -ID-Servers (im weiteren, soweit eindeutig, als "Server" bezeichnet) sind 
Speicherung und Organisation der Verwaltungsinformationen fur die Abwicklung des Proto- 
kolls zwischen den Teilnehmerknoten, insbesondere zur korrekten und efFizienten Nutzung 
von COB-IDs fur die Ubertxagung von Ethernet Frames. 
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Abbildung 6: Reg istrie rung eines Teilnehmers beim COB-ID-Server 

Bestandteil des COB-CD-Server-Protokolls ist ein dynamisches Initialisierungsprotokoll, mit 
dem sich ein neuer Teilnehmer beim COB-ID-Server registriert. Der Ablauf ist in Abbildung 
7 dargestellt. 

Sobald sich ein Teilnehmerknoten lokal initialisiert hat, sendet er eine Registrierungsanforde- 
rung mit einer well-known COB-ID an den COB-DD-Server. Diese well-known COB-ID ist 
zum Entwurfszeitpunkt festgelegt und wird von alien Teilnehmern fur die Registrierung ver- 
wendet. Insofern kann es theoretisch, namlich bei zeitgleicher Registrierungsanforderung 
durch mehrere Teilnehmer, zu einer Kollision kommen, die auf dem CAN-Bus zu einer er- 
kannten, fehlerhaften Ubertxagung fuhrt. Zur Auflosung des Konflikts wird entsprechend dem 
CSMA/CD-Verfahren vorgegangen. 

Bei erfolgreicher Registrierung teilt der Server dem sich registrierenden Teilnehmer eine pri- 
vate, eindeutige COB-ED zu, die die Teilnehmerstation fur jede weitere Komrnunikation mit 
dem Server verwendet. In dieser Antwortnachricht sowie in weiteren Steuernachrichten ver- 
wendet der Server eine zweite well-known COB-ID, fur die alle Knoten, die an dem Protokoll 
teilnehmen, standig empfangsbereit sein miissen, um Statusmeldungen oder Steuernachrichten 
entgegenzunehmen. Dies bedeutet aber auch, daB jede Nachricht des Servers von alien Kno- 
ten empfangen wird (Multicast). Die Empfanger miissen jeweils anhand des Paketinhalts 
auswerten, ob sie von der Nachricht betroffen sind. Der hierdurch erzeugte Aufwand ist auf- 
grund der im Verhaltnis zu Nutzdateniibertragungen selten stattfindenden Multicast- 
Ubertragung von Steuernachrichten als gering anzusehen. 



GR 99 P 85 



7 

Die beiden betxachteten well-known COB-IDs sind die beiden einzigen, zum Installations- 
zeitpunkt systemweit festgelegten Identifier, die durch das "IP iiber CAN"-Protokoll reserviert 
sind. Alle im weiteren verwendeten COB-EDs werden vom Server zugeteilt und konnen nach 
Gebrauch bei Bedarf wieder entzogen werden. Fur die dabei zur Verfugung stehenden COB- 
tDs sind derzeit im Server-Code feste Bereiche vorgegeben. Eine dynamische Festlegung 
entsprechender COB-ED-Pools, etwa zum [nitialisierungszeitpunkt des Servers, kann insbe- 
sondere die Bediirfnisse der sonstigen am CAN-Bus koexistierender Anwendungen beriick- 
sichtigen. Damit ist die Anforderung nach Vertriiglichkeit des Protokolls mit anderen CAN- 
Protokollen in optimaler Weise gegeben. 

Im weiteren werden Sendeauftrage der hoheren Protokollschicht fur Ethernet Frames und die 
daraus resultierenden Vorgange im COB-ID-Server-Protokoll betrachtet. Wird in einem Teil- 
nehmerknoten ein Ethernet Frame zum Senden ubergeben, so wird zunachst die Zieladresse 
im Ethernet Header uberpruft und abhangig davon, ob es sich urn eine reale Stationsadresse 
oder um eine Broadcast-Adresse handelt, verfahren. (Eine ebenfalls mogliche Multicast- 
Adresse kann wie eine Broadcast-Ubertragung behandelt werden und wird im folgenden nicht 
weiter betrachtet). 
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Abbildung 7: Zuteilung einer Punkt-zu-Punkt-COB-iD 

Eine Punkt-zu-Punkt-Ubertragung eines Ethernet Frames an eine bestimmte Station mit gege- 
bener MAC-Adresse beginnt mit der Anforderung eines COB-ID-Paares vom 
COB-ID-Server, wie in Abbildung 8 dargestellt. Die Zuteilung der zu verwendenden COB-ID 
erfolgt, wie oben beschrieben, iiber die well-known COB-ED und wird auch von alien anderen 
Stationen am Bus registriert, aber nur von der Partnerstation des Senders beriicksichtigt, die 
sich fur den ersten Identifier empfangsbereit macht und daraufhin ein CAN-Paket, adressiert 
mit der zweiten zugeteilten COB-ID als Bestatigung an die erste Station sendet, die sich fur 
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diesen Identifier empfangsbereit gemacht hat. Nun kann die Ubertragung des Ethernet Frames 
vonstatten gehen. 

Der sendende Knoten beginnt die Ubertragung des Ethernet-Frames (vgl. Abbildung 9) mit 
einem ersten CAN-Paket, das die Lange des Ethernet Frames und die ersten Nutzdaten ent- 
halt. Alle anderen Knoten empfangen dieses und die unmittelbar ohne weitere Kontrollinfor- 
mationen folgenden CAN-Pakete und fiigen diese zu einem empfangenen Ethernet Frame 
zusammen. 1st die Ubertragung des Frames vollstandig, wird er an die oberen Netzwerk- 
schichten weitergereicht. 

Handelt es sich um ein Broadcast-Paket, wird ahnlich wie im Fall einer Punkt-zu-Punkt- 
Ubertragung verfahren. Der sendende Teilnehmerknoten beantragt vom COB-ED-Server eine 
Broadcast-COB-ED. Die Zuteilung der zu verwendenden COB-ID erfolgt wiederum uber die 
well-known COB-CD und wird von alien anderen Stationen am Bus registriert, die sich in die- 
sem Falle alle auf den Empfang des Broadcast- Frames mit der neuen COB -ED konfigurieren 
konnen. 

Die fur einen bestimmten Zweck zugeteilten COB-EDs konnen bei erneuter Kommunikation 
desselben Stationspaares wiederverwendet werden, bis der COB-ED-Server sie aus Mangel an 
verfugbaren COB-EDs zuriickfordert. Auch bei einer Punkt-zu-Punkt-Ubertragung in umge- 
kehrter Richtung zu einer vorangegangenen Ubertragung wird das zugeteilte COB-ED-Paar 
verwendet, entscheidend sind alleine die teilnehmenden Stationen. Gleiches gilt fur erneute 
Broadcasts. 
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Abbildung 8: 
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Die Ruckforderung einer vom COB-ED-Server vergebenen COB-ED bzw. eines Paares wird 
eingeleitet, wenn die Anzahl der zur Vergabe im COB-ED-Server noch zur Verfiigung stehen- 
den COB-EDs einen kritischen Wert unterschreitet. Reihenfolge und Umfang der Ruckforde- 
rung sind strategieabhangig implementierbar. Eine einfache, bisher realisierte Emplementie- 
rung bedient sich eines FIFO-Algorithmus. Eine zeitliche COB-ED-Server-seitige Uberwa- 
chung der tatsachlichen Nutzung von vergebenen COB-IDs durch die Teilnehmerknoten ist 
moglich und kann dem COB-ID-Server als Grundlage fur z.B. einen LRU-Algorithmus zur 
Auswahl der Riickforderungen dienen. Zur Einleitung einer Ruckforderung sendet der COB- 
ED-Server fur jede betroffene Station eine Ruckgabe-Aufforderung, die die Static nsadresse 
des Knotens und die betreffende COB-ID enthalt. Eine noch uber den entsprechenden Kanal 
laufende Paketiibertragung kann von den Knoten abgeschlossen werden, bevor die Riickgabe 
der COB-ID jeweils vom darauf sendenden Knoten mit einer Ruckgabe-Antwort an den 
COB-ED-Server bestatigt wird. SchlieBlich fuhxt der COB-ED-Server die zuriickgegebenen 
COB-EDs wieder seinem Vorrat der vergebbaren COB-EDs zu und quittiert die erfolgte Ruck- 
nahme mit einer entsprechenden Kontrollnachricht. Daraufhin konnen die zugehorigen Sende- 
und Empfangsobjekte von den Knoten deinitialisiert und Eintrage in den lokalen Zuord- 
nungstabellen entfernt werden. Die Quittierung durch den COB-ID-Server ist vorgesehen, um 
zu verhindern, daB ein Knoten seine Empfangsbereitschaft fur eine COB-ED verliert, bevor 
die Gegenstelle alle Sendevorgange auf dieser ED eingestellt hat. Der geschilderte Vorgang 
fiir ein COB-ED-Paar gilt entsprechend auch fur zu Broadcast-Zwecken vergebene COB-IDs, 
wobei in diesem Fall nur ein Knoten und der COB-ED-Server beteiligt sind. 



